Columbia Kermit/kermit.zip/newsgroups/misc.20041116-20060924/000214_slash_dev_slas…[e-mail]_Thu Dec 1 11:46:44 2005.msg

Internet Message Format | 2020-01-01 | 4KB

Path: newsmaster.cc.columbia.edu!panix!newsfeed-00.mathworks.com!newscon06.news.prodigy.com!prodigy.net!border1.nntp.dca.giganews.com!nntp.giganews.com!postnews.google.com!f14g2000cwb.googlegroups.com!not-for-mail
From: "Mark Sapiro" <[e-mail]>
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Take command exiting...
Date: 30 Nov 2005 21:41:17 -0800
Organization: http://groups.google.com
Lines: 69
Message-ID: <[e-mail]>
References: <[e-mail]>
   <[e-mail]>
   <[e-mail]>
NNTP-Posting-Host: 209.182.169.133
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Trace: posting.google.com 1133415694 4467 127.0.0.1 (1 Dec 2005 05:41:34 GMT)
X-Complaints-To: [e-mail]
NNTP-Posting-Date: Thu, 1 Dec 2005 05:41:34 +0000 (UTC)
User-Agent: G2/0.2
X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20051012 Netscape/8.0.4,gzip(gfe),gzip(gfe)
Complaints-To: [e-mail]
Injection-Info: f14g2000cwb.googlegroups.com; posting-host=209.182.169.133;
   posting-account=iQNWIg0AAAAD2fStXNC9nwGlPdSqjWrI
Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:15460

malone wrote:
> That is just it, if it does not detect a problem or if it runs into a
> condition that was not previously available it continues with the input
> / output dialog. I do not want to ctrl-C out of the script of about 100
> command files to open command file #5  insert an end and then call the
> initiating script again.
>
> I know I could fix the problem and call only those files that were not
> called earlier but I would prefer to only bypass the command file that
> had the problem and continue processing the other 100 command files.
>
> What exactly is the Input cancellation command? and is that a way that
> I can cancel the input dialog and enter an end?


What are you doing in the 'command files'.

It seems you need to make them more robust. I.e., every 'output'
command should be followed by an 'input' with a time out that checks
for the expected response and that followed by an 'if failure ...' . If
you simply want to stop that command file, but continue the higher
level script, this could just be 'if failure end' or 'if failure end 0
message to print'. Other commands like send and get should also be
tested with 'if failure' or 'if success'.

Here's a piece of script as an example. These use 'end 1' because I
want this to signal failure to a caller, but you could use 'end 0' to
signal success. Of course, if you don't test success/failure/status in
the caller, it doesn't matter :-)

set host /pty ssh -e none -l \v(userid) \m(rhost).\m(rdomain)
if fail end 1 Unable to connect to \m(rhost).
input 30 assword:
if fail end 1 No password prompt.
output \m(pswd1)\13
input 20 \m(rhost)
if fail end 1 No shell prompt.
input 5 %
if fail end 1 No shell prompt.
output kermit -Y\13
input 20 C-Kermit>
if fail end 1 No Kermit prompt.
output set receive pathnames relative\13
set send pathnames relative
input 20 C-Kermit>
if fail end 1 No Kermit prompt.
output set file collision update\13
input 20 C-Kermit>
if fail end 1 No Kermit prompt.
output server\13
input 20 SERVE...
if fail end 1 Not in server mode.
input 2 \10
if fail end 1 How can this be?
...

In your case, you may need to test for something more complex than
another prompt or look for something with input that signals failure,
e.g.

input 5 error
if success end

Or you may need to test some environment variable or \v(exitstatus).

--
Mark Sapiro msapiro at value net       The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan